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Motion  of 
the  gate 


Figure  1:  A  driveway  gate 


1.  Introduction 


1  The  engineering  design  process  has  been  classified  into  four  stages,  namely,  (1)  Conceptual 
design  wherein  physical  concepts  and  engineering  principles  are  used  to  generate  prototypes 
that  are  expected  to  meet  given  design  specifications,  (2)  Parametric  design  wherein  geometry, 
form  and  material  parameter  values  are  chosen  for  each  feasible  conceptual  prototype,  (3) 
Configuration  design  involving  spatial  arrangements  and  sizing  of  the  components  of  the 
synthesized  prototype  and  finally  (4)  Embodiment  design  wherein  detailed  specifications  for 
the  product  are  generated  aided  by  thorough  engineering  analysis.  Successful  computer- 
design  aids  have  been  built  to  support  parametric  and  configuration  design  such  as  structural 
optimization  and  layout  tools.  Research  in  developing  models  for  design  computation  has 
primarily  focused  on  providing  tools  for  analysis  of  designed  artifacts  and  their  computerized 
representation  as  solid  models.  Only  limited  work  has  been  performed  to  provide  support 
for  design  synthesis  at  the  early  stages  of  design.  Tools  to  support  conceptual  design  have 
been  limited  in  their  expertise  because  of  the  variety  of  physical  concepts  that  need  to  be 
represented.  It  is  also  unclear  how  the  conceptual  design  phase  interacts  with  the  parametric 
and  configuration  design  stages.  An  example  design  problem  that  illustrates  the  different 
design  stages  and  highlights  the  need  for  tools  that  aid  conceptual  design  is  described  in  the 
following  section. 


1.1.  An  example  problem 

Consider  the  synthesis  of  an  electro-mechanical  drive  system  that  opens  and  closes  a  gate 
to  the  driveway  of  a  house  as  shown  in  Figure  1.  Given  a  signal  to  open  the  gate,  the 
drive  system  moves  the  gate  horizontally  on  guide-ways  in  a  particular  direction;  the  drive 
system  moves  the  gate  in  the  opposite  direction  when  given  the  signal  to  close  the  gate. 
Design  specifications  for  the  drive  system  are  the  frictional  force  that  resists  the  motion  of 
the  gate,  the  speed  variation  of  the  gate,  the  input  power  supply  to  the  drive  system  i.e.  the 
input  electrical  voltage  and  current  availability  and  variation  with  time.  A  drive  system  for 
the  gate  can  be  assembled  from  numerous  off-the-shelf  components  such  as  motors,  gears, 
linear  slides  and  other  mechanisms  to  meet  these  specifications,.  Four  possible  designs  of 
increasing  complexity  are  shown  in  Figure  2.  In  each  design,  the  thick  arrows  denote  the 
direction  of  power  flow.  Energy  from  the  electrical  source  flows  through  each  component 
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Figure  2:  Possible  designs  for  gate  drive  system 


and  is  finally  converted  into  work  moving  the  gate.  The  schematic  diagram  for  each  design 
denotes  the  power  connectivity  structure  between  different  components  (notated  as  boxes) 
and  is  called  the  device  topology  of  the  design.  The  choice  of  AC  or  DC  motors  in  the  device 
topologies  is  dictated  by  the  nature  of  the  electrical  source.  Designs  1  and  2  are  simple 
designs  wherein  the  gate  opens,  stays  in  the  open  position  for  a  brief  period  of  time  and  then 
closes.  Designs  3  and  4  involve  feedback  about  the  position  of  the  gate  denoted  by  the  thin 
arrow.  A  position  sensor  detects  the  limiting  positions  of  the  gate  and  triggers  a  directional 
switch  to  change  current  direction  in  design  3  and  the  bi-directional  valve  position  in  design 
4.  Each  component  in  the  device  topologies  in  Figure  2  has  a  well-defined  dynamic  behavior 
and  role  to  play  in  the  over-all  functioning  of  the  design.  For  example,  the  electrical  motor 
converts  electrical  power  into  rotary  mechanical  power  and  a  cam  converts  rotary  motion 
into  reciprocatory  motion.  The  choice  of  a  design  from  Figure  2  also  depends  on  metrics 
such  as  the  cost,  the  weight,  the  spatial  volume  and  reliability  of  each  component  in  the 
design  and  the  overall  assembly.  A  device  topology  is  generated  as  a  result  of  a  sequence  of 
design  decisions.  We  illustrate  the  design  choices  for  generating  the  gate-drive  system  device 
topologies  in  Figure  3.  The  process  of  choosing  the  correct  type  of  off-the-shelf  components 
i.e.  a  four-bar  mechanism  vs.  a  rack  and  pinion  mechanism  and  combining  these  components 
in  a  feasible  manner  that  provides  the  required  functionality  is  conceptual  design[l,  2].  The 
different  motor  and  mechanism  combinations  shown  in  the  figure  provide  conversion  of  rotary 
motion  to  translatory  motion.  Once  a  particular  combination  of  components  is  chosen,  the 
next  issue  is  sizing  these  components  i.e.  choosing  a  large  or  small  motor  with  large  or 
small  rack-pinion  medianism.  This  process  is  called  parametric  design.  This  is  illustrated 
in  the  figure  by  the  different  motor  and  rack-pinion  combinations.  An  associated  step  is 
the  process  of  choosing  spatial  orientations  for  each  component  and  forming  the  overall 
shape  and  size  of  the  drive  system  for  the  gate.  This  is  called  configuration  design.  As 
shown  in  the  figure,  the  motor  and  rack-pinion  can  have  a  number  of  relative  orientations 
depending  on  spatial  constraints  in  the  design  specification.  The  foregoing  example  describes 
the  synthesis  of  new  devices  in  contrast  to  the  task  of  routine  design  wherein  one  is  primarily 
involved  in  parametric  design  involving  resizing  of  components  given  a  particular  device 
topology.  Choices  of  components  and  device  topologies  in  the  conceptual  design  stage  may 
not  satisfy  parametric  or  configuration  requirements  and  the  process  of  design  has  to  be 
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Figure  3:  Design  process  for  the  gate  drive  system 

repeated  with  a  different  initial  choice  of  concepts  thus  leading  to  increased  product  design 
cycle  times  and  cost.  Computational  design  aids  that  provide  the  human  designer  the  ability 
to  generate  different  initial  concepts  i.e.  components  and  valid  component  topologies  given  a 
set  of  design  specifications  and  also  explore  the  interaction  effects  of  conceptual,  parametric 
and  configuration  choices  will  be  invaluable.  Such  aids  would  help  in  the  choice  of  off- 
the-shelf  components  and  their  consequent  assembly  without  recourse  to  synthesizing  new 
devices  from  scratch.  In  this  paper,  we  present  a  computational  scheme  to  generate  valid 
assemblies  of  components  given  design  specifications  and  also  perform  parametric  design  on 
the  synthesized  assemblies. 

Computational  aids  for  supporting  design  must  exhibit  certain  essential  characteristics. 
Since  the  space  of  feasible  designs  is  vast,  the  synthesis  algorithms  must  generate  all  designs 
on  request  or  some  valid  designs  depending  on  the  nature  of  the  design  specifications.  The 
design  algorithms  must  also  consider  measures  such  as  cost,  reliability,  robustness  etc.  to 
trade-off  various  design  alternatives  and  propose  only  those  solutions  that  satisfy  required 
design  criteria.  For  more  detailed  design  specifications,  the  synthesis  routines  must  provide 
design  solutions  that  contain  the  same  or  more  amount  of  design  detail.  The  design  algo¬ 
rithms  must  reflect  a  domain-independent  approach  such  that  an  algorithm  for  designing 
combinations  of  mechanical  devices  can  be  adapted  to  synthesize  hydraulic  devices. 

Finally,  in  the  case  of  electro- mechanical  devices,  the  devices  are  described  at  multi¬ 
ple  levels  of  detail  and  abstraction.  An  example  of  two  abstract  representations  for  an 
electro-mechanical  component  are  the  solid  model  representation  and  the  dynamic  differ¬ 
ential  equation  representation  of  the  device.  The  representations  support  different  kinds 
of  physical  information  relevant  for  design;  the  solid  model  provides  information  on  shape, 
volume,  weight  etc.  while  the  differential  equation  provides  information  on  the  dynamics  of 
the  device.  Therefore  the  synthesis  procedure  must  be  able  to  process  design  information  at 
and  across  different,  levels  of  abstraction.  Design  is  a  generative  task  wherein  a  variety  of 
feasible  designs  are  created  and  evaluated.  Design  is  computationally  more  expensive  than 
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analysis  of  a  given  design  alternative  based  on  a  given  physical  model  of  the  device.  Also 
the  information  available  during  the  generative  process  is  rather  incomplete  at  times  and 
the  variety  of  alternatives  for  each  design  decision  is  rather  large  leading  to  combinatorial 
explosion  of  choices.  Therefore  the  algorithms  must  make  efficient  use  of  partial  knowledge 
to  reduce  search. 

Conceptual  design  systems  such  as  IBIS  [3]  uses  a  graph-based  representation  for  modeling 
device  topology  but  fails  to  capture  time-dependent  behavior  of  physical  parameters.  Quali¬ 
tative  representations  of  device  behaviors  are  incomplete  with  respect  to  device  structure[4] 
and  also  the  dynamic  description  do  not  enable  combination  of  components.  The  substance- 
behavior-function  model  [5]  model  does  not  capture  physical  processes  but  is  more  a  descrip¬ 
tive  model  of  devices.  Kota  [6]  has  proposed  the  qualitative  motion  synthesis  approach  which 
focuses  on  kinematic  design  of  mechanisms.  A  qualitative  model  and  a  matrix-method  to 
combine  different  qualitative  motion  descriptions  is  used  to  build  devices.  A  rule-based  ap¬ 
proach  is  provided  in  [7]  for  synthesis  of  mechanisms.  A  predicate-logic  representation  is  used 
to  model  devices  and  a  complex  search  procedure  to  compute  new  designs.  Other  conceptual 
design  schemes  are  described  in  [2].  In  summary,  the  design  methods  proposed  so  far  have 
not  utilized  both  topological  information  about  devices  and  their  constituent  physical  process 
relationships.  From  the  viewpoint  of  the  staged  design  process,  no  computational  scheme 
with  a  well-defined  device  model  has  been  proposed  to  integrate  conceptual,  parametric  and 
configuration  design  stages  in  a  feasible  manner. 

A  computational  methodology  for  design  that  combines  generative  aspects  of  design  and 
also  combats  the  computational  inefficiency  in  a  feasible  manner  is  Case-based  design[8]. 
Case-based  reasoning  is  a  paradigm  that  aims  to  use  experiential  knowledge  gained  in  solv¬ 
ing  previous  problems  to  formulate  solutions  for  new  problems[9].  Primary  elements  of 
a  CBR  system  are  the  case-base,  wherein  previous  problems,  their  solutions,  models  etc. 
are  stored,  and  an  inference  mechanism  that  uses  the  information  stored  in  the  case-base. 
The  inference  mechanism  converts  the  given  problem  specifications  into  relevant  indices  for 
retrieving  cases  from  the  case-base,  retrieves  relevant  cases,  validates  the  retrieved  cases 
as  plausible  solutions  and  if  necessary  modifies  some  of  the  cases  to  meet  the  new  problem 
specification  and  proposes  a  new  solution.  Case-based  design  provides  for  use  of  previous  de¬ 
signs  and  fragments  of  complete  designs  as  partial  solutions  in  the  synthesis  process.  Having 
access  to  previous  designs  reduces  the  complexity  of  the  search  in  the  ill-structured  domain 
of  electro-mechanical  design.  Cases  provide  coherent  models  of  devices  across  multiple  ab¬ 
stractions  enabling  consistent  design  reasoning  across  different  representations  of  a  device. 
Since  a  case  captures  all  relevant  design  information,  it  provides  for  performing  conceptual, 
parametric  and  configuration  design  in  an  integrated  manner.  Cases  also  provide  a  means 
to  operationalize  design  knowledge  either  as  rules  or  as  descriptive  data  structures.  Cases 
also  provide  a  sort  of  feasibility  check  on  new  designs  by  providing  information  regarding 
success  and  failure  on  previous  designs,  with  respect  to  different  design  alternatives.  An¬ 
other  interesting  aspect  is  that  previous  cases  provide  designers  information  with  regard  to 
the  physical  realizability  of  various  designs  i.e.  guarantee  that  devices  can  be  manufactured 
with  reasonable  investments  of  capital  and  time.  The  CADET  [10,  8]  system  is  based  on 
the  qualitative  reasoning  framework  and  uses  Influence  graph  diagrams(ISD)  for  modeling 


10 


devices.  A  graph-based  indexing  scheme  is  used  to  retrieve  cases.  IDEAL[11]  and  Kritik[5] 
are  other  CBR-base  systems  of  note  for  synthesis  of  mechanical  devices  based  on  the  SBF 
device  models. 

A  CBR  based  design  methodology  raises  the  issue  of  the  definition  of  a  design  case  and 
how  a  design  case  is  to  be  represented.  A  design  case  representation  must  correspond  to  the 
various  models  of  the  physical  world  phenomena.  We  cannot  simply  structure  a  case  in  terms 
of  axiomatic  logic-theoretic  representations.  The  models  of  the  physical  world  in  engineering 
and  physics  are  non-linear  and  stochastic.  The  device  models  also  involve  quantitative  and 
temporal  variations.  A  rule-based  approach  is  not  flexible  enough  to  handle  these  different 
aspects  of  the  physical  world  in  a  consistent  manner  and  is  primarily  incomplete.  Design  rea¬ 
soning  to  a  certain  extent  involves  interpretation  of  these  complex  physical  models,  studying 
the  behavior  of  these  models  when  various  aspects  of  these  models  are  tweaked  and  choos¬ 
ing  the  right  combination  of  these  physical  models  to  create  feasible  designs  that  can  meet 
the  design  specifications.  Therefore  a  case-representation  requires  a  feasible  combination 
of  axiomatic  and  analog  models  of  physical  phenomena.  Further,  since  synthesis  involves 
combinations  of  components,  procedures  for  aggregating  and  combining  cases  need  to  be 
defined.  Combinations  of  cases  must  satisfy  all  physical  conservation  and  thermodynamic 
laws.  A  principled  way  of  combining  cases  and  ensuring  feasibility  of  the  combined  design 
is  required.  It  is  also  imperative  that  the  combination  of  cases  be  feasible  at  all  levels  of 
abstraction. 

We  have  developed  a  case-based  design  methodology  that  addresses  the  different  issues 
raised  in  the  foregoing  paragraphs.  Our  methodology  combines  bond-graph  based  device 
models  to  meet  design  specifications  in  a  systematic  manner.  In  our  CBR-model  of  design, 
the  case-base  consists  of  device  models  of  components  and  assemblies  of  components.  The 
steps  in  the  inference  procedure  are  shown  in  Figure  4.  Design  specifications  from  the  user 
are  transformed  into  indices  for  retrieval  of  cases  (devices)  from  the  case-base.  Cases  are 
retrieved  and  composed  into  an  assembly.  Each  synthesized  assembly  is  then  validated. 
Designs  can  be  validated  via  simulation  or  through  the  use  of  validation  rules.  Successful 
designs  as  well  as  failures  are  archived  in  the  case-base.  The  case-base  consists  of  cases  that 
store  design  information  related  to  both  conceptual  and  parametric  design.  The  conceptual 
and  parametric  design  tasks  are  interleaved  in  the  inference  mechanism.  An  interesting 
feature  to  note  is  that  the  CBR  mechanism  provides  an  explicit  inference  step  for  assembly 
of  retrieved  components  i.e.  to  perform  synthesis.  The  cognitive  model  of  the  CBR  process 
has  the  notion  of  retrieving  different  relevant  cases  from  memory  and  adapting  those  cases 
to  propose  a  new  solution.  Composition  of  cases  is  one  of  the  many  available  adaptation 
schemes  and  plays  a  critical  role  in  synthesis  of  assemblies  from  components. 

Bond-graph  based  representations  have  been  used  for  design  in  [12,  13,  14,  15,  16].  In 
[12], the  synthesis  procedure  generates  a  network  of  bondgraph  elements  with  bond-graph 
primitives  such  as  TF,GY,R,I,  C  elements  and  0-1  junctions  to  span  the  input  and  output 
bond-graph  chunks,  based  on  rules  that  aim  to  generate  differential  equations  of  a  prespec¬ 
ified  order.  An  exponential  search  procedure  is  used  to  generate  bond-graphs  for  electro¬ 
mechanical  single-input  single-output  systems.  In  [13],  bond  graphs  are  viewed  as  a  defining 
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Figure  4:  The  case-based  design  process 


a  a  grammar  and  synthesis  rules  that  transform  the  bond  graphs  are  defined.  We  extend 
the  usability  of  bond-graphs  as  a  device  representation  by  addressing  device  behavior  over 
time  in  the  design  specifications.  We  follow  a  systems-theoretic  approach  and  do  not  aim  to 
synthesize  embodiments  of  the  devices  but  identify  the  components  and  their  connectivities 
[17, 1].  Bond  graph  based  design  schemes  are  reviewed  in  detail  in  [18].  A  typology  of  devices 
has  been  developed  based  on  device  input-output  relations  that  capture  dynamic  behavior. 
Further,  these  input-output  relations  are  related  to  the  structural  aspects  of  the  device  such 
as  geometry  and  other  material  properties.  We  have  enhanced  the  role  of  bond  graphs  by 
observing  that  lumped  parameter  coefficients  in  bond-graph  relations  provide  a  convenient 
link  to  study  the  effects  of  device  structure  on  the  device  behavior.  For  example,  the  bond 
graph  model  of  a  pair  of  spur  gears  is  a,  mechanical  power  transformer  with  the  tooth  ratio 
of  the  gears  in  mesh  as  a  modulating  parameter.  The  ratio  of  the  teeth  is  the  only  structural 
parameter  that  affects  the  ideal  dynamic  behavior  of  the  device  with  respect  to  its  intended 
role  of  transforming  power.  This  tooth-ratio  provides  the  link  to  the  structural  aspects  of  the 
gear.  In  the  foregoing  example,  the  gear-ratio  required  can  be  obtained  by  a  variety  of  teeth 
ratios.  Other  attributes  of  the  gear  such  as  size,  teeth  geometries  and  material  properties  do 
not  affect  ’’ideal  gear  behavior”.  This  modeling  abstraction  facilitates  reasoning  across  device 
dynamic  behavior  and  device  structure.  We  hasten  to  note  that  though  bond-graph  analysis 
recognizes  the  existence  of  these  lumped  parameters,  they  have  been  considered  as  given  i.e. 
fixed  for  purposes  of  analysis  and  not  as  variable  entities  i.e.  entities  which  are  a  design 
choice.  The  case-representation  consists  of  a  bond-graph  based  device  model  that  captures 
relevant  physical  effects  and  an  axiomatic  model  that  aids  interpretation  of  the  device  model 
and  captures  parametric  and  geometric  attributes  of  the  device.  This  case  representation 
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allows  consistent  reasoning  across  device  behavior  and  structure.  Also  the  representation 
provides  for  monotonic  behavior  of  the  synthesis  procedure  i.e.  more  detailed  specifications 
generate  detailed  but  a  smaller  number  of  solutions.  The  device  representation  allows  for 
combining  components  or  cases.  Each  component  is  modelled  as  a  physical  system  with  a 
set  of  input  and  output  ports.  A  port  is  a  conduit  for  transfer  of  energy  (power)  into  and  out 
of  the  component.  When  components  are  assembled,  they  are  connected  at  their  ports.  The 
output  port  of  one  component  becomes  the  input  port  of  the  adjacent  component.  When  two 
devices  are  connected  at  their  ports,  the  power  and  energy  variables,  such  as  force,  velocity 
and  momentum,  at  each  port  are  constrained  to  be  equal.  Power  flows  from  one  device  to 
another  at  any  instant  of  time.  Power  flows  via  the  first  component  into  the  adjacent  one  as 
shown  in  Figure  2.  An  assembly  of  components  can  be  modelled  as  a  single  physical  system 
with  its  own  input  and  output  ports.  The  input-output  relations  of  the  components  can 
be  combined  to  determine  the  overall  input-output  relation  for  an  assembly.  Thus  given  a 
input-output  design  specification,  one  can  verify  whether  a  proposed  assembly  of  components 
can  meet  the  given  design  specifications.  The  verification  procedure  thus  provides  a  stopping 
criteria  for  the  generative  search  process  by  ensuring  that  non-feasible  design  alternatives 
are  not  further  explored.  The  bond-graph  model  captures  the  physical  effects  in  a  device  and 
cannot  be  put  into  a  one-to-one  correspondence  with  physical  components  of  a  device.  The 
port  models  of  devices  are  idealized  mathematical  versions  of  real  physical  embodiments  such 
as  masses,  springs,  and  gears.  Complex  two-port  systems  can  be  modelled  by  assembling 
these  two-port  models  serially.  Multiple  input-output  systems  can  be  assembled  from  one, 
two,  three  and  other  multi-port  components.  The  design  methodology  enables  the  synthesis 
of  assemblies  of  multiple  input-output  power  and  signal  devices. 

In  this  paper,  we  focus  on  the  synthesis  of  assemblies  consisting  of  components  with  one- 
input  and  one  output  port  to  illustrate  the  synthesis  procedure.  We  describe  a  computational 
scheme  that  combines  both  the  conceptual  design  and  parametric  design  tasks  using  the 
above  representation.  Configuration  design  tasks  are  not  addressed.  In  section  2,  we  present 
the  models  of  devices  and  their  representation.  We  also  describe  the  possible  types  of  design 
specifications  that  are  entailed  by  this  device  model.  In  Section  3,  we  present  the  synthesis 
algorithm,  in  Section  4,  we  present  domain  heuristics  with  respect  to  the  algorithm  and  the 
device  representation  and  conclude  in  Section  5. 


2.  Device  representation 


Our  proposed  device  representation  captures  physical  phenomena  as  energy  interactions  and 
device  structure  (topology)  as  a  directed  graph.  Device  functionality  is  dependent  upon  the 
ability  of  the  device  to  transform  either  power  or  signal  flows  through  the  device.  Each  such 
power  or  signal  transformation  is  provided  by  some  physical  effect  that  is  encapsulated  by 
the  device.  The  dynamic  behavior  of  an  assembly  of  components  is  dependent  on  the  device 
topology  and  the  transformation  behavior  of  each  component.  In  the  following  sections,  we 
describe  the  possible  power  transforming  behaviors  of  components  and  present  a  schema 
representation  of  power  devices. 
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2.1.  Energy  interaction  models  for  devices 

The  mathematical  model  of  energy  interactions  encapsulated  by  devices  is  based  on  the  bond 
graph  formalism  [19,  20,  21].  The  bond  graph  formalism  identifies  three  types  of  energy 
interactions  among  devices.  The  energy  behaviors  of  devices  are  energy  storage,  energy 
dissipation  and  energy  transmission.  Complex  device  behavior  arises  when  components  with 
storage,  dissipation  and  transmission  behavior  are  assembled  together.  The  dynamics  of 
physical  devices  are  derived  by  the  application  of  instant-by-instant  energy  conservation.  In 
the  bond-graph  formalism,  devices  are  modelled  by  components  connected  at  places  where 
power  can  flow  between  the  components.  Such  places  are  called  ports  and  devices  with  one 
or  more  ports  are  called  multiports.  Energy  storage  and  dissipation  behavior  is  exhibited 
by  devices  with  one  power  port.  Devices  such  as  springs,  resistors,  masses  etc.  can  be 
modelled  as  one-port  devices.  Energy  transmission  behavior  is  exhibited  by  devices  with 
multiple  input  and  output  ports.  A  tee-pipe  can  be  modelled  as  a  multi-port  device.  In  this 
paper,  we  focus  on  synthesis  of  single  input,  single  output  devices  called  two-port  devices. 
Devices  such  as  motors,  slider-crank  mechanisms,  cams  etc.  in  Figure  2  are  two-port  devices. 
The  overall  gate-drive  system  in  the  earlier  example  can  be  envisioned  as  a  two-port  device 
wherein  electrical  power  flows  in  at  the  input  port  and  is  used  to  mechanically  translate  the 
gate  at  the  output  port.  We  summarize  energy  transmission  behavior  of  a  two-port  device 
in  the  following  paragraph. 

Each  power  port  of  a  device  has  four  variables,  namely,  effort  (e(t)),  flow  {f(t)),  effort 
integral  (f  e{t)dt)  denoted  as  S{t)  and  flow  integral  (f  f(t)dt)  denoted  as  T{t)  .  The  power 
(■^(0)  equal  to  e{t).f{t).  e{t)  and  f{t)  are  called  power  variables.  The  energy  flow¬ 
ing  through  a  port  over  a  period  of  time  E(t)  is  given  by  /  e{t).f{t)dt  or  /  f{t).dS{t)  or 
j  e{t).dT{t).  8{i)  and  ^"{1)  are  called  energy  variables.  A  power  port  in  a  device  belongs  to 
an  energy  domain.  Power  and  energy  variables  can  be  identified  for  electro- magnetic  (EM), 
mechanical  translation  (MT),  mechanical  rotation  (MR),  thermal  (TH)  and  hydraulic  (HY) 
energy  domains  and  are  listed  in  Table  2.1.  The  first  column  lists  the  energy  domain  and  the 
ensuing  columns  the  effort,  flow,  power,  effort  integral,  flow  integral  and  energy  variables  of 
that  energy  domain.  Energy  domains  that  involve  radiative  transfer  of  energy  (solar,  light, 
acoustics  and  radiated  heat  energy)  are  not  modelled  though  successful  attempts  have  been 
made  to  extend  the  bond  graph  methodology  to  radiative  phenomena. 

For  a  two-port  device,  at  every  instant  of  time  ei(t).fi{t)  =  e2(t)./2(f),  where  the  subscript 
1  denotes  input  port  and  2  denotes  output  port.  The  above  equation  implies  that  in  a  two- 
port  system  whatever  power  is  flowing  into  one  side  of  the  2-port  is  simultaneously  flowing 
out  of  the  other  side.  To  satisfy  the  power  conservation  relation  in  a  physical  two-port 
system,  Ci  may  be  related  to  62  and  /i  may  be  related  to  /2.  Another  possibility  is  ei  may 
be  related  to  /2  and  /i  may  be  related  to  62.  Each  set  of  two  relations  is  called  a  device 
relation.  Table  2  shows  commonly  occuring  device  relations  in  a  variety  of  two-port  power 
components.  Each  relation  in  Table  2  is  denoted  D,  where  i  indicates  the  serial  number  of 
the  relation  in  the  table.  The  term  k  denotes  an  algebraic  coefficient  in  the  device  relations. 
^  and  S  denote  time  integrals  of  effort  and  flow  parameters.  There  are  numerous  other 
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P.Q 

Pressure 
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e.i 
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Entropy-flow 

* 

* 

* 

* 

Symbols  in  parenthesis  denote  conventional  symbolic  names  for  physical  parameters. 


Table  1:  Energy  and  Power  parameters 


No. 

Relations 

1 

62  =  k.ei,f2  =  fi/k 

2 

62  =  ei/k,f2  =  fi.k 

3 

62  =  k.fi,f2  =  ei/k 

4 

62  =  k.ei.Sin{P'i),f2  -  fi/k.Sin{Pi) 

5 

62  -  t\l{k.Sin{T^))j2  =  h-k.Sin{Tx) 

6 

62  =  k.6i.Sin{p2),f2  =  hlk.Sin{p2) 

7 

62  =  exl{k.Sin{p2)),h  =  fi.k.Sin{p2) 

8 

62  =  k.fi.SinlPi),^  =  6ilk.Sin{Pi) 

9 

62  =  k.fi.Sin(p2)-,f2  =  eilk.Sin{p2) 

iO 

62  =  hl{k.Sin{T-i))j2  =  6i.k.Sin{Pi) 

Bfl 

62  =  h!  {k.Sin{T2))i  f2  =  6i.k.Sin{p2) 

12 

62  =  k.6\.Sin{S\),  f2  =  f\lk.Sin{S\) 

13 

62  =  k.6i.Sin{S2),  f2  =  filk.Sin{£2) 

tm 

62  =  ei/{k.Sin{£i)),f2  =  fi.k.Sin{Ei) 

fm 

62  =  ei/lk.Sin{£2)),  f2  =  fi.k.Sin{€2) 

16 

62  =  k.fi.Sin{£i),f2  =  ei/k.Sin{£i) 

17 

62  =  k.fi.Sin{£2),f2  =  6ilk.Sin{£i) 

18 

62  =  fil{k.Sin{£i)),f2  =  6i.k.Sin{£i) 

tm 

62  =  fi/{k.Sin{£2)),f2  =  ei.k.Sin{£i) 

e2  =  k.6^.g{Tr)j2  =  hlk.g{rx) 

oa 

62  =  'H{ei)j2  =  fi-ei/H{ei) 

Table  2:  Two  port  device  relations 
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No. 

Algebraic  coefficients 

Lumped  parameters 

Relation 

in  device  relations 

of  device 

1 

^1 

Pi 

^1  =  Pi 

2 

kx 

Pi 

kx  =  p\ 

3 

kx 

Pl,P2 

kx  =  PxIp2 

4 

kx,k2 

Pl,P2 

kx  =  px,k2  =  P2 

5 

kx,k2 

PuP2 

kx  =  Px  +P2,^l  =  PxIp2 

Table  3:  Common  structural  relations 

types  of  device  relations  possible  as  long  as  they  satisfy  the  law  of  conservation  of  energy 
such  as  relations  D20  and  D211  where  Q  and  H.  denote  functions  such  as  exponential,  log 
etc.  Each  two-port  power  device  encapsulates  a  device-relation  and  the  generalized  effort 
and  flow  variables  at  each  port  are  instantiated  based  on  the  energy  domain  of  the  ports 
of  the  device.  A  pair  of  gears  is  modelled  by  (e2  =  k.ei,f2  =  fi/k),  where  the  input 
and  output  energy  domain  is  mechanical  rotation.  An  induction  motor  is  modelled  by 
62  =  k.fi.Sin{J^2)i  f2  =  eilk.Sin[!F2)  and  a  DC  motor  by  62  =  =  ^ifk  wherein  the 

input  energy  domain  is  electrical  and  output  energy  domain  is  rotary  mechanical. 

The  device  relations  between  the  port  variables  (efforts  and  flows)  have  algebraic  coeffi¬ 
cients,  such  as  fc,  as  shown  in  Table  2.  These  algebraic  coefficients  are  functions  of  lumped 
physical  parameters  that  depend  on  the  geometry  and  material  characteristics  of  the  de¬ 
vice.  Lumped  physical  parameters  do  not  have  a  spatial  extent.  For  example,  the  concept 
of  a  mass  of  a  component  concentrated  at  a  point  in  physical  space  is  a  lumped  parame¬ 
ter  approximation  though  the  mass  obviously  depends  on  the  spatial  volume  occupied  by 
the  component.  Relations  such  as  those  in  Table  2  may  have  multiple  algebraic  coefficients 
which  are  denoted  as  ki.  The  lumped  geometric  and  material  parameters  are  denoted  by  p,-. 
The  set  of  relations  that  map  each  ki  of  a  device  as  mathematical  functions  of  pi  is  called  a 
structural  relation.  The  lumped  parameters,  pi  are  called  structural  parameters.  A  variety  of 
structural  relations  exist  depending  on  the  number  of  coefficients  in  a  given  device  relation 
and  the  structural  parameters  of  the  device.  Table  3  shows  common  structural  relations. 
Each  structural  relation  is  denoted  as  Si  where  i  indicates  the  serial  number  of  the  relation 
in  table  3.  For  a  pair  of  gears,  the  algebraic  coefficient  k  (denoted  as  ki),  is  defined  by 

=  PiIP2,  wherein  each  lumped  parameter  {pi,i  =  1,2),  is  the  number  of  teeth  in  each 
gear.  For  a  DC-motor,  the  structural  relation  is  ki  =  pi  and  the  “lumped”  parameter  is  the 
field  current  that  excites  the  magnetic  coils  and  the  algebraic  term  in  the  device  relation  is 
the  motor  constant.  Therefore  by  not  simplifying  the  structural  relations,  more  information 
about  the  devices’  actual  structure  can  be  imported  into  the  bond  graph. 

Devices  exhibit  dynamic  output  behavior  when  they  are  driven  by  power  inputs.  Devices 
can  exhibit  dynamic  output  behavior  in  two  ways,  (1)  when  the  input  power  flow  at  the  input 
port  varies  and  (2)  when  the  lumped  parameters  vary  with  time.  Either  of  these  two  changes 
will  manifest  itself  as  variations  in  the  behavior  of  parameters  at  the  output  port.  When 
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both  kinds  of  input  effects  can  take  place  simultaneously,  the  output  dynamic  behavior  is  a 
superposition  of  the  two  input  effects.  In  this  paper,  we  synthesize  two-port  devices  wherein 
the  structural  parameters  are  not  allowed  to  vary  with  time.  Every  component  has  constant 
values  for  its  structural  parameters.  This  assumption  precludes  signal-dependent  modulation 
of  dynamic  behavior  of  devices. 


2.2.  Representation  of  dynamic  behavior  of  efforts  and  flows 

Design  specifications  for  a  required  device  are  primarily  specified  in  terms  of  corresponding 
effort  or  flow  time  histories  at  the  input  and  output  ports  since  one  does  not  know  the 
device  relation  before  synthesis.  Thus  a  representation  is  required  for  capturing  the  time- 
histories  of  effort  and  flow  parameters  at  the  ports  of  a  device.  In  this  section,  we  describe 
the  representation  of  time  histories  for  parameters  and  also  describe  its  significance  in  the 
modeling  of  devices  and  also  the  synthesis  process. 

Dynamic  output  behavior  is  obtained  by  dynamic  variations  at  the  input  port  of  a  device. 
For  example,  an  increase  in  input  power  can  be  obtained  by  increasing  the  effort  value,  flow 
value  or  both,  thus  causing  a  variation  in  the  output  port  variables.  Each  parameter  at  the 
input  and  output  port  describes  a  trajectory  over  time  that  describes  the  overall  dynamic 
behavior  of  the  device.  Theoretically,  an  infinite  number  of  such  continuous  trajectories  are 
possible  for  a  given  effort  or  flow  parameter.  We  model  a  single  time  trajectory  of  a  parameter 
as  piece-wise  continuous  functions  of  time.  Consider  the  trajectory  of  displacement  of  the 
follower  (with  the  cam  axis  as  reference)  during  rise  of  a  parabolic  cam  as  shown  in  Figure 
5.  The  follower  has  a  constant  acceleration,  linearly  increasing  velocity  and  a  parabolic 
displacement  over  the  follower  rise  time-period  t^ise  ^-nd  the  same  behavior  in  the  opposite 
direction  during  the  follower  fall  time-period,  tfaii  as  shown  in  figure. 

The  time  trajectory  of  a  parameter  is  discretised  into  a  sequence  of  regions,  (Ti,  r2,  Ta...), 
Ti  denotes  the  ith  time  interval  and  Ti  is  the  interval  containing  the  time  origin.  For  the 
displacement,  velocity  and  acceleration  trajectories  for  the  cam  in  the  foregoing  example, 
there  are  two  distinct  regions  trise  and  tfaii  which  constitute  Ti  and  T2.  In  each  region  T,-,  the 
parameter  trajectory  with  time  is  approximated  as  a  closed-form  function  of  time,  t.  The 
possible  parameter  functions  of  time  that  we  have  implemented  are  shown  in  Table  4.  y  can 
be  efforts  or  flows  at  the  ports  of  devices  and  t  denotes  time,  m,-  and  c,-  denote  constants. 
Each  parameter-time  relation  is  called  a  P-relation  and  is  denoted  P,-  where  i  denotes  the 
serial  number  in  the  table.  The  time  trajectory  of  a  parameter  over  a  given  period  of  time 
can  be  approximated  by  a  set  of  P-relations.  We  restrict  our  representation  only  to  the  above 
relations,  since  any  complex  time- history  of  a  parameter  can  be  approximated  by  the  above 
relations  in  a  piece-wise  manner.  A  parameter  trajectory  can  lie  only  in  the  first  and  fourth 
quadrants  of  the  parameter-time  coordinate  system  since  time  is  always  positive.  All  physical 
parameters  are  scalars.  A  positive  or  negative  magnitude  for  a  physical  parameter  denotes 
the  direction  of  action  along  a  given  direction  in  coordinate  system  chosen  by  convention.  A 
positive  magnitude  indicates  that  the  physical  parameter  acts  in  the  same  direction  as  the 
given  vector  and  a  negative  magnitude  denotes  that  it  acts  in  the  opposite  direction  to  the 
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Figure  5:  Displacement  trajectory  for  parabolic  cam  follower 


No. 

Relation 

1 

y  =  mi.t  +  Cl 

2 

y  —  mi.Sin{t)  +  C2 

3 

y  =  mi.Log{t)  +  C4 

4 

y  =  mi.Exp{t)  +  C5 

5 

y  —  mi.t  +  +  cq 

Table  4:  Parameter  functions  of  time 
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Figure  6:  Possible  parameter  trajectories 


given  vector.  Thus  each  relation  listed  in  the  Table  4  can  be  used  to  describe  time  trajectories 
as  shown  in  Figure  6.  y  —  Ci  can  represent  trajectory  3  while  y  =  mj.t  +  m2.t^  +  ce 

can  represent  trajectory  2.  Each  such  relation  does  not  have  any  information  regarding  the 
direction  of  action  of  a  physical  parameter.  For  example,  y  =  m\.Sin(t)  +  can  be  used 
to  represent  trajectories  1  and  4  in  Figure  6  since  both  are  sinusoidal  with  respect  to  time. 
Physically  the  two  trajectories  denote  two  different  physical  events,  trajectory  1  describes 
a  sinusoidal  variation  in  magnitude  such  as  an  oscillating  pressure  pulse  while  trajectory  4 
describes  a  change  in  magnitude  and  direction  such  as  the  reciprocating  motion  of  the  slider 
in  a  slider-crank  mechanism.  Reciprocation  is  indicated  by  the  sinusoidal  curve  in  trajectory 
4  switching  between  the  first  and  fourth  quadrants.  Thus  it  is  essential  that  we  distinguish 
between  the  two  trajectories,  1  and  4.  Knowledge  of  m  and  Cj  in  the  parameter  relations  is 
not  enough  as  shown  by  trajectories  5  and  6  in  Figure  6.  Though  the  two  trajectories  lie 
on  the  same  line  and  are  represented  similarly,  they  denote  different  physical  events.  The 
only  information  that  is  needed  to  discriminate  is  the  direction.  Each  parameter  trajectory 
is  represented  by  a  Pi  which  is  also  annotated  with  directional  information.  The  literal  + 
denotes  that  the  parameter  relation  describes  a  trajectory  that  lies  only  in  the  first  quadrant, 
literal  -  denotes  that  the  parameter  relation  describes  a  trajectory  that  lies  only  in  the  fourth 
quadrant  and  literal  +-  denotes  that  the  parameter  relation  describes  a  trajectory  both  in  the 
first  and  fourth  quadrant.  Hence  trajectory  1  will  be  annotated  with  a  +  while  trajectory 
4  will  be  annotated  by  a  +-.  Thus  a  parameter  trajectory  in  a  discretised  time  region  is 
denoted  by  a  list  (parameter  relation,  quadrant,  time  duration)  wherein  parameter  relation 
is  a  triplet  {snum,c,m)  where  snum  is  the  serial  number  from  Table  4,  m  and  c  are  lists 
of  coefficient  values  for  the  relation;  a  quadrant  is  one  of  the  literals  +,-  or  +-  and  time 
duration  is  a  pair  («< ,  /<)  where  St  and  ft  denote  start  time  and  end  times  for  trajectories.  The 
follower  acceleration  trajectory  in  Figure  5  over  the  rise  and  fall  periods  will  be  represented 
as  shown  in  Table  5.  trise  and  tf  all  denote  rise  and  fall  times.  The  first  column  lists  the 
time-region  and  the  second  column  the  parameter  relation,  quadrant  and  time  durations.  In 
each  region,  the  linear  constant  velocity  is  represented  by  y  =  mi.t  -t-  Ci  (denoted  by  the  first 


Time- region 

Trajectory  representation 

Ti 

(1, (cl) , (ml)) ,  +,  (0  trise) 

T2 

(1, (c2) , (m2)) ,  (trise  trise+tfall) 

Table  5:  Velocity  trajectory  for  parabolic  cam  follower 


element  l).  Specific  trajectories  are  defined  when  the  constants  mi  and  c*  are  defined.  Thus 
in  Table  5,  =  0,m2  =  0,ci  =  1  and  C2  =  1  describes  a  constant  velocity  of  1  m/s  over  the 

follower  rise  and  fall  periods.  The  different  quadrants  for  the  velocity  trajectory  during  rise 
and  fall  are  denoted  by  the  literals  +  and  -.  The  trajectory  of  follower  displacement  during 
trise  and  tfaii  Can  be  represented  by  y  =  rui.t  +  m2.t‘^  +  Ce  i.e.  parabolic  with  appropriate 
coefficients. 

Thus  to  describe  the  dynamic  behavior  of  a  device  over  a  given  time-period,  one  would 
discretise  the  time-period  into  discrete  regions  and  in  each  region,  describe  the  behavior  of 
input  and  output  port  parameters  as  functions  of  time.  Thus  for  a  two-port  device  with  one 
discretised  time  region,  four  parameter  trajectories,  one  each  for  the  input  and  output  port 
efforts  and  flows  are  required  to  completely  describe  the  device  behavior.  Usually  a  physical 
device  that  encapsulates  a  device  relation  does  not  produce  outputs  for  all  kinds  of  input 
effort  and  flow.  Only  certain  kinds  of  parameter  relations  are  allowed  for  the  input  effort 
and  flow.  For  example  a  DC-motor  will  not  produce  a  rotary  torque  if  given  a  sinusoidal 
input  voltage.  A  device  relation  for  modeling  a  device  is  also  annotated  with  all  the  possible 
inputs  it  can  handle.  From  the  fifteen  possible  trajectories  for  input  port  effort  and  flow  i.e 
five  types  of  P,  and  three  directional  quadrants,  the  valid  trajectories  are  listed  in  the  device 
representation. 

Why  is  such  a  complex  representation  of  time-history  behavior  required  ?  First,  the 
design  specifications  for  a  device  are  given  in  terms  of  nominal  corresponding  time-histories 
for  the  efforts  and  flows  at  the  ports  of  device.  For  example,  design  specification  for  a 
motion  generating  mechanism  is  in  terms  of  requisite  time-profiles  for  the  output  linkages. 
Secondly,  the  constitutive  device  relations  described  in  the  previous  section  can  produce  a 
variety  of  output  effort  and  flow  time  histories  depending  on  the  input  effort  and  flow  time 
histories.  In  theory,  therefore  a  single  device  can  be  driven  by  an  infinite  number  of  different 
types  of  inputs.  Representing  a  device  by  cataloging  all  its  input-output  parameter  time- 
histories  is  cumbersome.  Therefore  though  the  device  relation  is  a  succinct  representation 
of  the  device  input-output  relation,  a  representation  for  describing  time-histories  is  required 
to  enable  choices  of  devices  that  may  provide  by  requisite  behavior.  This  choice  can  only 
be  made  by  driving  the  device  with  the  given  input  time-history  and  observing  the  output 
behavior.  We  note  therefore,  that  for  a  given  time-history  specification,  an  infinite  number 
of  devices  or  their  combinations  can  be  proposed  as  feasible  solutions.  Synthesis  therefore 
involves  generating  combinations  of  devices  and  testing  them  for  different  inputs  as  specified 
in  the  design  specifications.  If  requisite  output  behavior  is  obtained,  the  new  design  is 
accepted.  From  an  algorithmic  viewpoint,  one  needs  to  match  the  different  input-output 
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Figure  7:  Design  specifications  for  gate  drive  system 


time-history  specification  to  all  possible  device  relations  that  can  provide  the  requisite  input- 
output  transformation.  In  the  following  section  we  describe  the  use  of  the  above-described 
parameter  trajectory  representation  for  providing  design  specifications  regarding  dynamic 
behavior  of  a  two-port  device. 


2.3.  Design  specifications 

Design  specifications  outline  the  input  and  output  port  energy  domains  and  trajectories  for 
effort  and  flow  at  either  port  over  a  given  time  duration.  We  illustrate  representation  of 
design  specifications  with  the  gate-drive  system  example.  In  Figure  7  the  gate-drive  system 
is  shown  as  a  black-box  whose  input  and  output  energy  domains  are  electrical  and  mechanical 
translatory  domain.  The  trajectories  for  the  input  voltage,  output  force  required  to  move 
the  gate  and  the  velocity  of  the  gate  are  also  shown.  The  output  force  is  a  constant  (500N) 
and  changes  direction  from  each  half-cycle  of  opening  and  closing  the  gate.  The  velocity 
of  the  gate  starts  from  zero  and  reaches  a  steady  value  (0.1  m/s)  and  then  reduces  to  zero 
over  each  half-cycle.  There  is  a  well-defined  dwell  period  (2  seconds)  between  each  half  cycle 
(8  seconds)  when  the  gate  remains  open  or  closed  as  the  case  may  be.  Actually  this  dwell 
period  could  be  large  (open  gates)  but  for  illustrative  purposes  we  have  chosen  2  seconds. 
The  velocity  behavior  can  be  approximated  as  a  constant  velocity  neglecting  the  quick  rise 
to  steady  value.  The  parametric  values  for  force  and  the  velocity  are  known  and  specified 
as  shown  in  the  figure.  The  input  voltage  is  a  DC-voltage  which  is  held  at  a  constant  value 
of  50  volts.  The  input  current  profile  is  not  fixed  as  it  depends  on  the  load  that  is  driven 
and  is  allowed  to  be  any  trajectory  that  meets  the  load  requirements.  The  trajectories  have 
been  discretised  into  three  distinct  regions  as  shown  in  the  figure.  The  first  time  region  (gate 
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Attribute 

Value 

Input  port  energy  domain 

EM 

Output  port  energy  domain 

MT 

Time-region  I 

Time  region  II 

Time-region  III 

Input  effort  trajectory 

((1  50  0)  +  (0  8)) 

((1  50  0)  +  (8  10)) 

((1  50  0)  +  (10  18 

Input  flow  trajectory 

((♦  *  (0  8)) 

(*  ♦  (8  10)) 

(*  ♦  (10  18))) 

Output  effort  trajectory 

((1  500  0)  +  (0  8)) 

(-  -  (8  10)) 

((1  500  0)  -  (10  1 

Output  flow  trajectory 

((1  0.1  0)  +  (0  8)) 

(-  -  (8  10)) 

((1  0.1  0)  -  (10  1 

*  denotes  value  is  unspecified,  -  denotes  that  value  is  null. 

Table  6:  Design  specification  representation  for  gate  drive  system 


opening)  lasts  from  0  to  8  seconds,  the  dwell  period  lasts  from  8  to  10  seconds  and  the  third 
time  region  lasts  from  10  to  18  seconds.  The  design  specification  representation  for  the  gate- 
drive  system  is  shown  in  Table  6.  Each  parameter  trajectory  in  a  region  is  approximated  by 
the  the  relation  y  =  mi.t  +  Ci  with  mi  =  0  (a  constant  linear  trajectory)  and  Ci  equal  to 
their  parametric  value.  Thus  ci  =  50  volts  for  the  input  effort,  Ci  =  500  Newtons  for  the 
output  effort,ci  =  0.1  m/s  for  the  output  flow  and  ci  is  unconstrained  for  the  input  flow. 
Since  there  are  three  discretised  regions  over  a  complete  cycle  of  the  gate  operation,  there  are 
three  trajectory  specifications  for  effort  and  flow  parameters  at  each  port.  Based  on  these 
design  specifications,  the  synthesis  procedure  must  identify  a  case  or  a  combination  of  cases 
that  converts  the  input  port  parameter  variations  into  parameter  variations  at  the  output 
port.  If  multiple  cases  are  composed,  the  procedure  must  also  identify  the  topology  in  which 
the  cases  are  connected  i.e.  the  connectivity  between  the  different  ports  of  the  components 
based  on  the  design  specifications. 

Thus  far  our  discussion  has  addressed  the  representation  of  components.  A  component 
device  is  defined  by  a  single  device  relation.  An  assembly  of  components  is  defined  by  each 
component  device  relation  and  the  topology  of  the  assembly.  Based  on  the  topology  of  the 
assembly  and  the  component  device  relations,  it  is  possible  to  obtained  a  closed-form  device 
relation  for  an  assembly.  Consider  design  1  in  Figure  2.  The  motor  is  represented  by  device 
relation  e2  =  ^•/i,/2  =  ei/fc  and  the  slider-crank  mechanism  by  62  =  eif{k.Sin{fi)),f2  = 
The  overall  device  relationship  obtained  by  eliminating  the  common  port 
variables  is  63  =  fi.ki/k2.Sin{J='2)  and  fs  =  ei.k2.Sin{:F2fki)  where  the  port  parameters  are 
as  shown  in  Figure  8.  This  is  equivalent  to  device  relation  Du.  An  assembly  of  component 
devices  may  or  may  not  have  a  unique  closed-form  device  relation  as  listed  in  Table  2. 
The  device  relation  for  such  assemblies  can  be  inferred  from  the  device  relations  of  the 
components.  The  structural  relation  for  an  assembly  of  components  is  the  combined  set 
of  all  structural  relations  of  its  components.  The  dynamic  behavior  of  an  assembly  can  be 
changed  by  changing  the  structural  parameters  of  any  of  its  components.  Also,  it  is  fairly 
obvious,  that  the  input  and  output  effort  and  flows  for  an  assembly  can  be  described  by 
the  parameter  trajectory  representation  developed  in  the  earlier  sections.  The  connectivity 
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e2  =  kjfl 
f2  =el/kj 


e3  =  e2/l^.Sin(f2) 
f3  =  f2.k2.  Sin(f2) 


b. 


el,fl 


e3,D 


e3  =  l^fiy  k^Sin(f2) 
f3  =el.^.Sin(f2yk^ 

Figure  8:  Device  relationship  for  an  assembly  of  components 


between  components  in  an  assembly  is  represented  by  a  directed  acyclic  graph  where  the 
directed  arcs  denote  power  flow  path  and  the  nodes  denote  components.  Thus  the  device 
topology  of  assembly  1  in  Figure  2  will  be  E  — >  Motor  Slidercrank  — >  E  where  E 
denotes  the  environment  which  is  external  to  the  assembly.  Complex  devices  can  be  built 
by  combining  both  components  and  sub-assemblies.  This  representation  provides  a  uniform 
representation  for  both  components  and  sub-assemblies. 

This  concludes  our  discussion  on  modeling  device  behavior  and  its  representation.  Essen¬ 
tial  features  of  the  device  representation  are  as  follows: 


•  Devices  (components  and  their  assemblies)  are  modelled  as  entities  that  allow  trans¬ 
mission  of  power  through  conduits  called  ports. 

•  Device  input-output  behavior  is  modelled  by  device  relations. 

•  Device  dynamic  behavior  is  linked  to  the  structure  of  the  device  through  structural 
relations. 

•  The  time  histories  of  the  efforts  and  flows  at  the  ports  is  modelled  by  parameter 
relations. 

The  representation  thus  provides  a  convenient  way  of  describing  device  behavior  in  terms 
of  its  input-output  relation  or  the  nature  of  the  trajectories  of  its  port  parameters.  Further 
since  the  device  physics  is  modelled  based  on  the  bond  graph  formalism,  it  ensures  that 
combinations  of  components  will  be  physically  feasible  without  violating  any  physical  laws. 
Further  the  port-models  of  devices  provide  a  convenient  means  to  composing  assemblies 
by  connecting  components  at  their  ports.  In  the  following  subsection,  we  use  the  above- 
described  device  model  to  represent  components  and  assemblies  as  cases  in  a  case-base. 
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2.4.  Cases  and  case-base  organization 


The  content  and  organization  of  the  case-base  determines  the  validity  of  the  solutions  and 
efficiency  of  the  retrieval  algorithm  in  CBR-based  design  systems.  In  our  implementation, 
the  case-base  stores  a  variety  of  devices  encapsulating  different  device  relations  and  structural 
relations.  A  device  relation  defines  a  class  of  devices  that  exhibit  similar  dynamic  behavior 
i.e.  the  input-output  relationship.  A  particular  physical  realization  (instance)  of  a  device, 
belonging  to  the  class  defined  by  a  given  device  relation,  is  defined  when  the  structural 
relation  is  defined  and  values  for  the  structural  parameters  are  chosen.  A  spur-gear  pair 
with  gear-ratio  two  is  defined  when  a  gear  with  forty  teeth  is  meshed  with  a  gear  with 
twenty  teeth.  It  is  of  interest  to  note  that  a  device  relation  can  be  obtained  by  a  variety  of 
physical  realizations  each  with  different  structural  relations  or  with  different  values  for  the 
lumped  structural  parameters.  For  example,  a  gear-ratio  of  two  can  a  be  obtained  either  by 
choosing  helical  gears  that  provide  a  gear-ratio  of  two  or  by  meshing  a  spur  gear  with  twenty 
teeth  with  a  ten  teeth  spur  gear.  Each  case  in  the  case-base  is  a  well-defined  instance  of  a 
device  relation  and  structural  relation.  Thus  if  a  case  exists  in  the  case-base  it  is  physically 
realizable. 

Each  case  is  represented  as  a  schema  with  the  attributes  and  possible  values  as  shown  in 
Table  7.  The  device  relations  are  chosen  from  those  in  Table  2.  The  valid  possible  input 
parameter  trajectories  are  denoted  by  a  list  of  consisting  of  pair  {snum,  quadrant)  where 
snum  is  the  serial  number  from  Table  4  and  quadrant  is  as  specified  earlier.  The  list  of 
lumped  parameters  is  a  list  of  symbols  where  each  symbol  is  a  literal  that  denotes  a  lumped 
parameter  such  as  Area,  Gear-ratio  etc.  Our  representation  has  a  well-defined  vocabulary 
of  commonly  used  lumped  parameters  that  capture  device  geometry  and  material  properties. 
Since  each  case  is  a  physically  realizable  instance  of  a  device,  the  lumped  structural  param¬ 
eters  have  fixed  values.  Many  devices  that  are  available  allow  a  range  of  values  for  their 
structural  parameters.  For  example  a  gear  transmission  (an  assembly  of  gears)  provides  a 
range  of  gear  ratios.  For  such  devices  with  variable  structural  parameters,  a  range  of  nomi¬ 
nal  values  for  the  structural  parameters  are  listed.  The  directed-graph  representation  of  the 
device  topology  is  an  incidence  matrix  representation  wherein  each  node  corresponds  to  a 
component  denoted  by  a  symbol.  The  right-hand  side  of  each  equation  in  device,  structural 
and  parameter  relations  in  Tables  2,3  and  4  are  represented  as  trees  where  each  node  of  the 
tree  is  the  function  name  (a  literal)  and  the  leaves  are  arguments  (literals)  of  that  function. 
Such  trees  can  be  represented  as  recursive  lists  in  prefix  notation.  Shown  in  Figure  9  is 
the  tree  representation  of  the  relation  j/  =  mi.t  +  -f  ce  from  Table  4  and  its  recursive 
form  as  a  list  is  (+  (*  ml  t)  (*  m2  t)  c5).  A  complete  equation  is  represented  as  a  pair 
(left-hand-side  right-hand-side)  wherein  left-hand-side  is  a  literal  naming  the  parameter  and 
right-hand-side  is  the  recursive  definition  of  the  function.  A  device,  structural  or  parameter 
relation  is  represented  as  a  list  of  such  equations.  Table  8  shows  the  schema  for  a  DC  motor 
with  field  current  strength  variable  between  two  and  five  amperes. 

An  organized  case-base  provides  for  efficient  retrieval  during  the  synthesis  process.  The 
cases  in  the  case-base  can  be  classified  into  a  typology  as  shown  in  Figure  10.  Each  level 


24 


ml  t 
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Figure  9:  Representation  of  parabolic  parameter  relation 


Attribute 

Value 

Device  name 

Symbolic  name  of  device 

Input  port 

A  symbol  naming  port 

Output  port 

A  symbol  naming  port 

Input  port  energy  domain 

OneofMT,  MR,  TH,  EM,  HY 

Output  port  energy  domain 

OneofMT,  MR,  TH,  EM,  HY 

Device  relation 

Di  from  Table  2 

Feasible  inputs 

List  of  valid  input  parameter  trajectories 

Structural  relation 

Si  from  Table  3 

Structural  parameters 

List  of  lumped  parameters  of  device 

Structural  parameter  values 

Range  of  values  for  structural  parameters 

Components 

List  of  components  of  device 

Device  topology 

A  directed  graph  representation  of  topology 

Table  7:  Schema  for  a  device 


Attribute 

Value 

Device  name 

DC-motor-l 

Input  port 

PI 

Output  port 

P2 

Input  port  energy  domain 

EM 

Output  port  energy  domain 

MR 

Device  relation 

62  =  fc-/i,/2  =  ei/A: 

Feasible  inputs 

((!,+) (2, +) (3,+) (4,+)(5,+)(l,-)(2,-)(3,-)(4,-)(5,-) 

Structural  relation 

II 

Structural  parameters 

(Field-current) 

Structural  parameter  values 

((2  5)) 

Components 

0  (A  null  list  denotes  no  components) 

Device  topology 

0 

Table  8;  Schema  for  a  particular  DC-motor 
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Figure  10:  Typology  of  two-port  power  devices 


Key 

Description 

Value  for  DC-motor 

k. 

Input  and  output  port  energy  domains 

EM-MR 

k2 

Device  relation 

D3 

kz 

Assembly  or  component 

Component 

^4 

Structural  relation 

SI 

ks 

Structural  parameters  of  device 

Field-current 

Values  of  structural  parameters 

2 

Table  9:  Indexing  keys  for  a  device 

of  the  hierarchy  refers  to  a  particular  attribute  of  a  case.  The  first-level  denotes  the  energy 
domains  for  input  and  output  ports.  The  second  level  denotes  the  device  relation.  The  third 
level  denotes  if  a  case  is  a  component  or  an  assembly.  The  fourth  level  identifies  the  type  of 
structural  relation,  the  fifth  level  names  the  lumped  parameters  and  the  sixth  level  specifies 
the  nominal  ranges  for  the  lumped  parameters  of  a  device.  DC-motors  and  gears  are  shown 
indexed  by  the  typology. 

The  hierarchical  classification  scheme  provides  a  unique  index  for  every  case.  A  composite 
key,  Ki  of  the  type  {ki,k2,h,ki,h,k6)  can  be  generated  and  assigned  for  every  case  based 
on  the  above  defined  hierarchy.  Each  ki  that  constitutes  the  composite  key  is  described  in 
Table  9.  The  first  column  names  the  key,  the  second  column  describes  the  key  and  the  third 
column  gives  the  value  of  the  key  for  the  DC-motor  case  of  the  previous  example.  Thus 
given  that  the  value  of  ki  is  EM-MR  where  EM  denotes  that  the  input  port  of  the  case  is 
electro-mechanical  and  MR  denotes  that  the  output  port  of  the  device  is  rotary  mechanical, 
we  can  retrieve  the  DC-motor  case.  One  can  also  retrieve  DC-motors  if  it  is  given  that 
we  require  all  devices  that  have  device  relation  D^.  It  is  obvious  that  the  slot  values  of 
the  case-schema  can  be  used  to  generate  the  composite  key  for  a  given  case.  Retrieval  of 


cases  from  the  case-base  is  performed  by  specifying  the  composite  key  K.  The  composite 
key  (EM-MR,D3, Component, SI, Field-current ,2)  will  retrieve  only  the  specific  case  in  Ta¬ 
ble  8.  A  composite  key  (EM-MR,D3, Component, SI, Field-current,*)  where  *  denotes  a 
don’t-care  will  retrieve  all  DC-motors  with  field-current  as  the  structural  parameter.  The 
key  (EM-MR, *,*,*,*,*)  will  retrieve  all  motors  (including  AC-motors)  and  further  other 
assemblies  such  as  motor  and  gear  combinations.  The  key  (EM-MR, D3, *,*,*,*)  will  retrieve 
all  DC-motors  only.  The  attributes  that  constitute  the  composite  key  K  are  ordered  from 
the  most  general  to  the  most  specific  key  based  on  the  typology.  Since  every  case  in  the 
case-base  is  indexed  by  the  composite  key,  the  retrieval  algorithm  uses  a  given  composite 
key  and  retrieves  all  cases  that  match  the  key.  An  exact  match  is  required  between  the 
corresponding  elements  of  the  key  to  a  case  and  the  given  specifications  in  the  query.  Details 
of  index  organization  and  implementation  are  beyond  the  scope  of  this  paper. 

Consider  the  design  specification  for  the  gate-drive  system  in  Table  6.  The  initial  design 
specification  only  provides  element  kx  of  the  composite  key,  (fci  =  EM-MT).  The  other  elements 
of  the  composite  key  are  not  specified.  The  synthesis  task  involves  generating  possible  values 
for  those  other  elements  of  the  composite  key  that  are  unspecified.  The  parameter  trajectories 
provided  in  the  design  specification  provide  the  requisite  information  to  generate  the  values 
for  other  elements  of  the  composite  key.  Thus  design  can  be  viewed  as  the  process  of 
generating  all  the  elements  of  the  composite  key  and  once  all  the  elements  are  known,  a 
feasible  design  is  obtained.  Each  design  alternative  can  be  viewed  as  a  choice  of  values  for 
each  unknown  element  of  the  composite  key.  Conceptual  design  is  essentially  the  task  of 
generating  values  for  the  elements  ki,i  =  1,2, 3, 4, 5  and  parametric  design  involves  choosing 
the  value  for  element  fee.  As  the  design  process  proceeds  from  conceptual  design  to  parametric 
design,  values  for  specific  keys  are  identified  and  the  number  of  feasible  cases  is  further 
reduced.  In  the  following  section,  we  describe  the  synthesis  algorithm  that  proposes  a  variety 
of  possible  values  for  each  element  of  the  composite  key  in  a  principled  manner,  retrieves  cases 
based  on  the  proposed  composite  keys,  eliminates  infeasible  combinations  of  by  evaluating 
combinations  of  cases  using  the  parameter  trajectory  information  provided  in  the  design 
specifications  and  thus  further  refines  the  values  of  the  elements  of  the  composite  key  to 
generate  valid  designs. 


3.  The  case-based  design  procedure 


As  described  in  the  previous  section,  conceptual  and  parametric  design  tasks  are  equivalent  to 
generation  of  the  right  combination  of  values  for  the  elements  of  a  composite  key.  The  design 
task  is  complicated  since  there  are  a  number  of  alternatives  for  each  element  of  the  composite 
key.  Therefore  there  a  number  of  alternative  combinations  of  these  composite  key  element 
values  that  can  meet  the  design  specification  and  thus  there  are  a  number  of  design  solutions. 
We  note  that  we  have  not  provided  any  subjective  criteria  such  as  cost,  weight,  volume  etc. 
as  part  of  the  design  specifications.  If  such  information  were  provided  with  the  design 
specifications,  the  additional  specifications  would  be  used  to  choose  amongst  the  variety 
of  physically  realizable  alternatives. The  synthesis  process  can  be  organized  into  two  stages. 
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Figure  11:  Power-flow  path  representation  in  devices 


namely,  (1)  Given  a  desip  specification  as  in  Table  6,  retrieve  cases  from  the  case-base  that 

can  satisfy  the  specification,  i.e.  transform  the  input  parameter  trajectories  into  the  required 

output  parameter  trajectories,  and  (2)  If  no  single  case  can  be  found  to  satisfy  the  design 

specifications,  then  compose  cases  from  the  case-base  to  generate  a  new  design  We  describe 

a  synthesis  algorithm  wherein  both  these  tasks  are  interleaved.  The  algorithm  consists  of 

three  essential  procedures,  namely,  elaboration,  retrieval  and  verification.  Elaboration  can 

be  viewed  as  the  task  of  generating  all  possible  alternatives  for  elements  h  and  k2  of  the 

composite  key.  Retrieval  is  the  task  of  retrieving  cases  based  on  values  of  and  k2  to  obtain 

possible  values  for  ki,z  =  3, 4, 5, 6.  If  values  for  more  keys  are  given,  then  more  specific  cases 

would  be  retrieved  Verification  is  the  task  of  eliminating  all  the  infeasible  cases  retrieved 

^  parameter  trajectory  information  provided  in  the  design 

specification.  We  describe  each  of  these  procedures  and  present  a  synthesis  algorithm  using 

® 


3.1.  Elaboration 

Power  flow  path  from  the  input  port  to  output  port  in  a  two-port  device,  whose  device 
topo  ogy  IS  not  known,  can  be  described  by  the  graph  where  and  denote 

input  and  output  power  ports.  Power  flow  in  a  device  with  two  components  is  given  by  the 
graph  Pin  -1  Pinter  ->■  Pout  where  Pinter  is  the  common  port  shared  by  the  two  components 
as  shown  in  Figure  11.  The  directed  graph  denotes  that  the  input  port  of  the  first  compo¬ 
nent  is  connected  to  the  environment  and  the  output  port  of  the  first  component  feeds  into 
to  the  input  port  of  the  second  component.  The  output  port  of  the  second  component  is 
connected  to  the  environment.  The  port  pinter  is  the  output  port  for  one  component  and 
an  input  port  for  the  adjacent  component.  Each  arc  in  the  directed  graph  is  equivalent  to 
a  component  and  thus  two  nodes  (ports)  in  the  directed  graph  are  spanned  by  a  compo¬ 
nent.  Llaborahon  is  the  process  of  generating  a  directed  graph  p^ . from 

Pin  ->■  Pi . Pn-\  Pout-  Thus  elaboration  is  the  process  of  introducing  a  new  common  port 

m  a  given  power  flow  path  thereby  introducing  another  additional  component  in  the  device 
topology.  The  elaboration  process  is  equivalent  to  the  process  of  generating  an  internal  struc¬ 
ture  or  device  topology  iov  a  two-port  device  to  transform  the  input  parameter  trajectories  to 
output  parameter  trajectories.  Each  component  that  spans  two  ports  provides  a  particular 
in  of  power  transformation  depending  on  the  device  relation,  Di  that  relates  the  the  input 
and  output  ports  of  the  component.  The  design  specification  does  not  explicitly  provide 
information  on  the  kind  of  transformation  required  by  specifying  the  overall  Di  required 
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Figure  12:  Elaboration  tree 


between  the  input  and  output  ports  of  the  required  device.  This  information  is  implicit  in 
the  parameter  trajectory  specifications  provided  as  part  of  the  design  specifications.  The 
elaboration  procedure  proposes  possible  combinations  of  component  device  relations  that 
can  meet  the  specifications. 

Elaboration  is  a  heuristic  procedure  and  has  been  used  for  case  index  generation  in  [10]  . 
Given  a  directed  graph  for  elaboration,  the  elaboration  procedure  splices  the  arcs  between 
two  nodes  of  the  graph  and  introduces  a  new  node.  Elaboration  of  pj„  — >  pout  generates 
Pin  Pinter  Pout-  The  energy  domains  of  the  input  and  output  ports  of  a  device  are 
given  by  the  design  specification.  The  intermediate  ports  that  are  introduced  can  belong  to 
one  of  five  energy  domains  listed  earlier.  A  new  port  is  introduced  between  the  output  port 
and  the  penultimate  port  in  the  directed  graph  to  ensure  that  only  unique  directed  graphs 
are  generated.  Thus  if  energy-domains  of  the  power  ports  were  considered,  introduction  of 
a  single  intermediate  port  in  a  directed  graph  generates  five  new  elaborated  graphs.  Thus 
the  elaboration  procedure  creates  a  tree  of  “elaborations”  where  each  node  of  the  tree  is 
a  directed  graph  denoting  a  particular  topology  of  power  flow  as  shown  in  Figure  12.  In 
the  figure,  the  input  energy  domain  is  mechanical  rotation  and  the  output  energy  domain 
is  medianical  translation.  Each  node  of  the  tree  has  an  additional  port  with  respect  to  its 
parents.  Each  parent  node  has  five  children  nodes  though  all  five  have  not  been  shown  due 
to  space  limitations.  The  directed-graph  data  structure  at  each  node  of  the  elaboration  tree 
is  called  an  Elaboration  index.  Each  elaboration  index  at  every  node  of  the  elaboration  tree 
is  equivalent  to  the  elaboration  index  at  the  root  of  the  tree.  For  example,  a  device  that 
provides  a  power  flow  path  from  the  electro-mechanical  domain  (EM)  to  rotary  mechanical 
(MR)  domain  is  physically  equivalent  to  an  assembly  of  two  components  that  are  connected 
in  series,  wherein  the  first  one  provides  a  power  flow  path  from  electro-medianical  domain 
(EM)  to  rotary  mechanical  (MR)  domain  and  feeds  into  a  component  that  provides  a  power 
flow  path  from  rotary  mechanical  (MR)  domain  to  rotary  mechanical  (MR)  domain.  Hence 
each  elaboration  index  is  a  possible  alternative  for  the  element  ki  of  the  composite  key  to 
the  case  that  meets  the  design  specifications. 

Synthesis  of  two  port  devices  involves  connecting  components  in  a  certain  topology  to 
meet  the  input-output  trajectory  specifications.  Elaboration  generates  all  possible  device 
topologies  for  a  two-port  device,  that  are  comprised  of  only  two-port  devices,  given  the 
energy  domains  of  its  input  and  output  ports.  To  identify  the  components  that  span  two 
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nodes  in  the  device  topology,  we  also  need  to  know  the  device  relation  between  the  two 
ports.  Each  arc  in  the  device  topology  can  be  described  by  a  device  relation  from  Table 
2.  Thus  if  there  are  m  arcs  in  an  elaboration  index  and  N  device  relations,  there  are  N'^ 
combinations  of  devices  that  have  the  same  elaboration  index.  Each  such  combination  of 
component  device  relations  is  a  viable  alternative  value  for  element  ^2  of  fh®  composite  case 
that  satisfies  design  specifications.  Since  the  overall  device  relation  is  not  explicitly  provided 
with  the  design  specifications,  we  propose  all  possible  combinations  of  component  device 
relations  as  viable  solutions.  Thus  each  arc  of  a  given  elaboration  index  is  instantiated  with 
a  device  relation  to  generate  a  retrieval  index.  A  retrieval  index  with  n  arcs  is  denoted  by  the 
n-tuple,(ci,  ....c„)  where  each  c,-  is  a  5-tuple  {piniPouti€-ini^out,devi).  pin  and  pout  are  literals 
that  denote  input  port  and  output  ports.  e,„  and  Cout  are  one  of  the  literals  EM,MT,MR,HY,TH 
denoting  the  energy  domains  of  pin  and  pout-  devi  denotes  the  serial  number  of  the  device 
relation  from  Table  2  that  spans  the  ports  p,„  and  pout- 

A  composite  key  of  the  type  (kl,k2, *,*,*,*)  can  be  generated  for  every  arc  of  the 
retrieval  index  wherein  kl  denotes  the  energy  domains  of  the  two  ports  that  are  at  either 
nodes  of  the  arc  and  k2  denotes  the  device  relation.  Let  arc  i  of  the  retrieval  index  retrieve  mi 
cases  from  the  case-base.  Thus  a  retrieval  index  with  n  arcs  will  retrieve  fliLi  combination 
of  cases.  Consider  one  combination  of  cases  retrieved  using  a  key-index  of  n-elements  i.e. 
retrieving  one  case  each  for  an  elaboration  index  with  specified  device  relations  for  its  arcs. 
The  combination  is  denoted  as  a  list,  (casej,  ....,case„)  wherein  case,  is  the  case  schema.  Each 
such  combination  of  cases  is  called  an  assembly,  A.  The  assembly,  A,  will  be  a  singleton  set 
when  cases  are  retrieved  for  the  elaboration  index  at  the  root  of  the  elaboration  tree.  Each 
assembly  that  is  composed  has  to  be  validated  to  ensure  that  meets  the  design  requirements. 
In  the  following  section,  we  provide  a  scheme  to  eliminate  all  invalid  combinations  of  cases. 


3.2.  Case  verification 

Once  an  assembly  is  obtained,  we  need  to  verify  that  the  assembly  can  produce  the  requisite 
output  parameter  trajectories  for  given  inputs.  An  assembly  can  fail  if  (1)  the  device  relation 
of  the  overall  assembly  is  invalid  and  (2)  if  the  structural  parameters  of  its  component  cases 
are  invalid.  The  overall  device  relation  of  an  assembly  may  be  invalid  when  the  device-relation 
for  one  of  its  components  is  invalid  i.e.  a  wrong  combination  of  component  devices  has  been 
generated.  Even  if  the  combination  of  components  can  provide  the  requisite  transformation 
between  input  and  output,  they  might  be  invalid  because  of  scaling  errors  due  to  erroneous 
combination  of  structural  parameter  values.  We  present  a  verification  procedure  to  check 
whether  a  given  combination  of  cases  can  transform  the  input  parameter  trajectories  to  the 
output  parameter  trajectories  for  a  single  time  region.  We  motivate  the  procedure  with 
a  simple  example  of  validating  a  single  device  (case).  Assume  that  a  device  with  device 
relation,  Di  ,which  is  (e2  =  k.ei,f2  =  fi/k),  has  been  retrieved.  For  the  sake  of  clarity,  we 
also  assume  that  the  retrieved  case  has  the  same  input-output  energy  domains  as  required 
by  the  design  specifications.  The  design  specifications  for  the  input  and  output  parameter 
trajectories  for  the  time  region  are  as  shown  in  Table  10.  The  first  column  specifies  the 
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Parameter 

Specification 

Relation 

Pspec'P 

((l,0,kl) ,+,(0  t-end)) 

y  =  mx.t  +  Cl 

Pspecp 

((1,0,  g),+,(0  t-end)) 

y  =  mx.t  +  Cl 

Pspec°p^ 

((2,0,m) ,+, (0  t-end)) 

y  =  mx>Sin{t)  +  C2 

Pspecf^ 

((l,c,0) ,+, (0  t-end)) 

y  =  mx-t  +  Cl 

Table  10:  An  example  specification 

effort  and  flow  parameter  at  the  input  and  output  ports  and  the  second  column  specifies 
the  required  the  time  history  of  the  efforts  and  flows.  The  effort  and  flow  trajectories  in 
the  speciflcation  at  input  and  output  ports  are  denoted  as  Psptc^  ^PsptCj  ^Pspec^  and 
PspecfK  The  third  column  lists  the  parameter  relation  required  in  the  speciflcation  for 
illustration.  Pspec^^^  has  a  sinusoidal  trajectory  whereas  PspeP^ ,PspecJ  and  Pspecf*  are 
linear  in  nature.  kl,g,m  and  c  denote  numeric  constants.  (0,t-end)  denotes  the  duration 
of  each  trajectory. 

Device  relations  are  validated  by  symbolically  solving  a  system  of  equations  involving  the 
parameter  relations  specifying  the  input  and  output  parameter  trajectories  and  the  device 
relation  equations.  Given  a  device  relation  and  the  output  parameter  trajectories,  the  input 
parameter  trajectories  can  be  obtained  by  symbolically  solving  for  the  inputs.  For  example 
consider  the  relation  y  =  kx  wherein  k  is  constant.  Given  that  x  =  fP  wherein  /  is  constant 
and  t  is  the  independent  variable,  one  can  obtain  y  =  kfP  by  eliminating  x.  Alternatively 
given  y  —  kfP  and  y  =  fcx,  one  can  obtain  x  as  a  function  of  the  independent  variable  t. 
Similarly,  given  the  output  parameter  trajectory  as  a  function  of  time,  we  can  obtain  the 
input  parameter  trajectory  as  a  function  of  time  from  the  device  relation  by  symbolically 
eliminating  the  output  parameter.  Now  if  the  device  relation  is  to  be  valid,  the  input 
parameter  trajectory  obtained  by  elimination  must  match  the  input  parameter  trajectory  of 
the  design  specification  else  the  device  relation  is  invalid. 

The  output  parameter  relations  Pspecf  *  and  Pspecf*  and  the  device  relation  Di  are 
symbolically  solved  to  obtain  the  input  parameter  relations  P solvj^  and  Psolvj  as  functions 
of  time.  If  the  solved  relations  PsolP'^  and  Psolvj^  match  P spec'J^  and  Pspepp  ,  then  the 
device  relation  is  considered  valid.  Symbolically  solving  the  output  specification  in  Table 
10  and  Di  gives  Psolvp  =  m*Sin(t)/k  where  k  is  the  algebraic  coefficient  in  the  device 
relation  and  Psolvp  =  c*k.  The  specification  Pspepp  does  not  match  the  solved  relation 
Psolv'p  since  it  is  not  a  constant  but  a  linear  function  of  time.  Pspecp  does  not  match 
Psolvf  since  it  is  not  a  sinusoidal  function.  Hence  Psolv  and  Pspec  do  not  match  and  we 
can  conclude  that  the  the  case  retrieved  is  not  a  valid  solution. 

For  an  assembly  of  n  cases,  where  casei  is  connected  to  the  input  port  and  castn  is 
connected  to  the  output  port,  ,  we  repeat  the  solve-match  procedure  starting  from  the  output 
port  and  castn  to  obtain  the  output  specifications  for  castn-x  and  proceed  to  obtain  Psolv 
for  the  input  port.  We  match  Psolv  with  Pspec  for  the  input  port  parameters.  If  they  match 
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the  combination  of  cases  is  considered  a  valid  design  that  meets  the  design  specifications. 

The  above  described  validation  scheme  can  be  improved  if  we  note  the  following:  Pspec 
and  Psolv  might  not  match  for  two  reasons,  namely,  (1)  The  two  relations  might  be  com¬ 
pletely  different  i.e.  they  are  two  different  equations  and  (2)  The  two  equations  may  have 
the  same  morphology  but  have  different  coefficients  c*  and  m*-.  Thus  matching  of  Psolv 
and  Pspec  can  be  done  at  two  levels,  (1)  where  one  matches  only  on  the  morphology  of  the 
relations  iieglecting  the  values  of  the  coefficients  and  (2)  where  one  considers  the  values  of 
the  coefficients  too.  Matching  at  level  1  is  concerned  only  with  the  classes  of  device  relations 
while  at  level  2  we  are  concerned  with  the  structural  parameter  values.  If  matching  at  level 
1  fails  then  it  means  that  combination  of  cases  retrieved  by  the  retrieval  index  will  not  result 
in  a  valid  assembly  that  can  would  have  the  desired  behavior.  Further  details  of  matching 
parameter  relations  are  presented  in  Section  4.  The  elaborate-retrieve-solve  cycle  is  repeated 
for  each  time  region  of  the  parameter  trajectories.  Assemblies  (combination  of  cases)  that 
can  handle  the  complete  trajectory  are  finally  returned  as  viable  solutions  to  the  design 
specification.  In  the  following  section  we  present  the  complete  algorithm  and  illustrate  it 
with  solutions  generated  for  the  gate-drive  system. 


3.3.  Synthesis  algorithm 

The  main  steps  of  the  synthesis  procedure  are  as  follows: 


1.  The  design  specifications  for  the  first  time  interval,  7\,  are  chosen  and  an  elaboration 
tree  is  created.  The  root  index  of  the  tree  has  the  energy- domains  as  in  the  design 
specifications. 

2.  Device  relations  are  introduced  in  the  elaboration  index  and  retrieval  is  performed  with 
the  retrieval  indices  thus  generated.  Case  retrieval  returns  all  cases  that  match  the 
given  energy  domains  and  device  relation. 

3.  For  each  case  thus  retrieved,  case  verification  is  performed  by  symbolically  solving  the 
device  relation  and  output  time  histories  for  the  input  time-histories.  Cases  that  are 

successfully  verified  are  further  checked  for  the  values  of  their  structural  parameter 

values. 

# 

4.  Successful  cases  are  returned  as  solutions  for  the  first  time  interval  and  checked  with 
the  design  specifications  for  the  remaining  time  intervals. 

5.  If  no  cases  are  obtained,  the  root  index  is  further  elaborated  by  adding  a  new  port  and 
thus  a  new  component.  Device  relations  are  introduced  for  each  arc  of  the  elaboration 
index  and  cases  are  retrieved  for  the  retrieval  indices  thus  obtained.  Cases  are  verified 
again  by  symbolic  elimination  for  each  of  the  time  intervals.  The  procedure  iterates 

until  a  successful  solution  is  obtained  or  a  predetermined  level  in  the  elaboration  tree 
is  reached. 
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We  illustrate  each  of  the  above  steps  of  the  procedure  with  the  synthesis  of  a  device  topology 
for  the  gate-drive  system. 


3.4.  Synthesis  of  the  gate  drive  system 

1.  The  design  specifications  for  the  gate-drive  system  are  shown  in  Table  6.  The  effort  and 
flow  trajectories  have  been  discretised  into  three  regions  and  the  synthesis  procedure 
begins  with  the  initial  time  region  set  to  the  opening  half-cycle  of  the  gate  which  is 
the  first  time-region.  An  elaboration  tree  has  the  root  elaboration  index  pem  Pmt 
is  instantiated. 

2.  Retrieval  is  performed  with  retrieval  indices  pem  ^  Pmt  where  each  D,-  is  a  device 
relation  from  Table  2.  A  key,  AT,  generated  from  the  retrieval  index  pem  ^  Pmt  will 
be  (EM-MT,D1, *,*,*,*).  Case  retrieval  is  performed  with  these  indices. 

3.  In  the  case-base  implemented,  there  are  no  power  devices  that  directly  span  this  energy 
domain.  Hence  no  cases  are  retrieved  for  any  retrieval  index  for  the  elaboration  index 
Pem  Pmt-  Hence  further  elaboration  is  required. 

4.  Elaboration  of  the  index  pem  Pmt  generates  five  new  indices.  Elaboration  in¬ 
dices  Pem  Pem  Pmt  and  pem  Pmt  Pmt  are  not  considered  since  a 
sub-index  {pem  Pmt)  of  that  index  has  failed.  Retrieval  indices  are  generated 
for  the  elaboration  index  pem  —*■  Pmr  Pmt-  The  combination  of  cases  for  the 
elaboration  index  pem  Pmr  Pmt  are  listed  in  Table  11.  The  first  column  gives 
the  device  relations  for  each  arc  (from  input  to  output)  and  the  second  column  lists 
the  corresponding  devices.  Table  12  lists  the  device  relations  in  terms  of  the  effort 
and  flow  relationships  for  convenience.  The  retrieval  index  pem  ^  Pmr  ^  Pmt  re¬ 
trieves  the  combination  of  cases  (Induction-motor,  Rack-pinion-mechanism).  The 

retrieval  index  pem  ^  Pmr  ^  Pmt  retrieves  the  combination  of  cases  (DC-motor, 
Rack-pinion-mechamism).  The  sub-index  pmr  ^  Pmt  retrieves  a  slider-crank  mech¬ 
anism,  scotch-yoke  and  sinusoidal  cam  mechanism.  The  sub-index  pmr  ^  Pmt  also 
retrieves  a  straight-line  cam  mechanism. 

5.  Case  verification  is  performed  for  each  possible  combination  of  cases  shown  in  Table 
11.  Consider  the  assembly  consisting  of  the  AC-motor  and  Rack-pinion  mechanism. 
Solving  62  =  k.ei,f2  =  fi/k  and  the  output  specifications  Cout  =  500  and  font  =  0.1 
we  obtain  that  the  torque  (effort)  output  of  the  AC-motor  must  be  500/A:  and  the 
angular  velocity  (flow)  output  must  be  0.1  *  A:,  k  is  the  tooth- ratio  of  the  rack-pinion 
mechanism.  Since  cases  are  instantiated  for  structural  parameters  in  the  case-base,  k 
will  have  a  value  and  we  assume  a  case  with  k=  20  has  been  retrieved.  Hence  the  torque 
required  is  25  Nm  and  the  angular  velocity  2  rad/sec.  We  solve  62  =  k.f\.Sin{T2)i  f2  — 
eilk.Sin{J^2)  for  a  motor  with  A;  =  5,  to  obtain  that  the  input  voltage  to  the  motor 
must  be  105'm(16)  and  input  current  must  be  5Cosec{16).  We  compare  this  with 
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Device  relations 

Cases 

Dz,D\ 

(DC-motor  Rack-pinion) , (DC-motor  Straight -line-cam) 
(DC-motor  Linear-screw-mechanism) 

DziD^ 

(DC-motor  Slider-crank-mechauiism) , (DC-motor  scotch-yoke) 
(DC-motor  sinusoidal-caim) 

Dq,Di 

(AC-motor  Rack-pinion) , (AC-motor  Straight -line-cam) 
(AC-motor  Linear-screw-mecheuiism) 

DsjDs 

(AC-motor  Slider-crank-mechauiism) , (AC-motor  scotch-yoke) 
(AC-motor  sinusoidal-cam) 

Table  11:  Cases  retrieved  for  index  pem  ^  Pmr  — ^  Pmt 


No 

Relations 

Di 

62  =  k.ei,f2  =  fi/k 

Dz 

€2  =  k.fij2  =  ei/k 

Ds 

62  =  ei/{k.Sin{J^i))j2  =  fi.k.Sin(J^i) 

D9 

62  =  k.fi.Sin{f‘2),f2  =  eijk.Sin{J^2) 

Table  12:  Device  relations  for  cases  in  Table  11 


the  design  specifications  and  find  that  a  constant,  non-sinusoidal  voltage  is  the  input 
specification.  Thus  all  combination  of  cases  with  an  AC-motor  will  be  rendered  invalid. 

Consider  the  design  DC-motor  and  Rack-pinion-mechanism.  Considering  the  same 
rack-pinion  mechanism  as  retrieved  above,  the  torque  output  requirements  for  the 
motor  is  25  Nm  and  the  angular  velocity  is  2  rad/sec.  We  solve  62  =  k.fi,  /2  =  Ci/k  for 
the  DC-motor  with  k  =  10,  to  obtain  input  voltage  required  is  20  volts  and  an  input 
current  of  2.5  amperes.  The  voltage  and  current  parameter  relations,  obtained  by 
solving,  match  the  specifications  since  both  are  constant  values.  Voltages  are  constant 
and  since  the  relation  of  electrical  current  as  function  of  time  is  not  specified,  any 
relation  is  considered  valid.  Thus  a  DC-motor  and  Rack-pinion  combination  is  a  viable 
solution.  Though  the  voltage  relations  match  morphologically,  their  values  are  not 
equal.  The  synthesis  algorithm  considers  the  above  combination  as  a  failure  and  checks 
all  different  combinations  of  DC-motors  and  rack-pinion  mechanisms  that  exist  in  the 
case-base  till  the  correct  combination  is  located.  If  no  such  combination  exists  in  the 
case-base  it  fails  and  proceeds  to  try  another  retrieval  index.  We  have  not  implemented 
procedures  that  hypothesize  structural  parameter  values  once  a  morphological  match 
is  obtained. 

6.  A  feasible  solution  is  a  DC-motor  with  motor  constant  k  =  25  and  a  rack-pinion 
mechanism  with  a  gear-ratio  of  20.  We  note  that  an  infinite  number  of  combinations 
are  possible  parametrically.  The  algorithm  retrieves  only  those  that  are  available  in 
the  case-base.  The  case  base  serves  as  a  source  of  devices  that  have  been  physically 
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realized  and  work.  Hence,  retrieving  devices  from  the  case-base  eliminates  possible 
downstream  failures  due  to  manufacturing  and  eliminates  searches  for  other  parameter 
combinations.  Other  possible  solutions  for  the  opening  half  cycle  are  DC-motor  and 
Straight-line-cam  and  the  combination  of  DC-motor  and  Linear-screw-mechanism. 
Composition  of  device  relations  (DsjDs)  fails  to  produce  any  solution  because  of  the 
sinusoidal  term  in  the  device  relation  D5  and  case  verification  results  in  failure. 

7.  The  feasible  solutions  are  verified  for  each  of  the  remaining  two  time  regions.  The 
search  procedure  terminates  once  solutions  are  found  and  case  retrieval  is  not  per¬ 
formed  for  the  elaboration  indices,  pem  Pth  Pmt  and  pem  — ^  Phy  — ^  Pmt- 
Valid  combination  of  devices  as  solutions  for  the  gate  drive  system  are  the  combi¬ 
nations:  (DC-motor  Rack-pinion) , (DC-motor  Straight-line-cam)  and  (DC-motor 
Linear-screw-mechanism) . 


In  the  following  sections,  we  analyze  the  complexity  of  the  search  and  discuss  heuristics  that 
have  been  implemented  to  guide  the  search. 


3.5.  Complexity  of  the  synthesis  procedure 

Computational  efficiencies  for  retrieval  algorithms  are  primarily  determined  by  the  orga¬ 
nization  of  the  case-base.  The  hierarchical  classification  and  generation  of  indexing  keys 
provides  a  near  linear  performance.  The  exploration  of  the  design  space  is  determined  by 
the  branching  factor  of  the  elaboration  tree  and  the  number  of  device  relations  that  are 
defined.  At  a  given  level  n  of  the  elaboration  tree,(  level  0  is  root,)  there  are  n  -1- 1  arcs.  Let 
there  be  totally  m  possible  device  relations.  Also  if  the  case-base  has  N  instances  for  each 
device  relation,  then  the  total  number  of  designs  that  need  to  be  explored  at  level  n  is  at 
most  (A^m)"+^  .  The  branching  factor  of  the  elaboration  tree  is  five  since  we  consider  only 
five  energy  domains.  Thus  the  total  number  of  combinations  of  cases  seaxched  to  a  depth 
n  is  at  most  Thus  the  search  performed  is  affected  both  by  the  number  of 

cases  in  the  case-base  and  the  number  of  device  relations  in  Table  2.  The  domain  heuris¬ 
tics  described  in  the  following  guide  the  exploration  of  this  very  large  space.  The  search 
efficiency  can  be  improved  as  the  system  acquires  more  cases.  The  acquired  assemblies  can 
be  directly  retrieved,  thus  reducing  the  number  of  combinations  of  individual  components 
explored.  For  example,  if  assemblies  of  motors  and  gears  were  represented  as  cases  in  the 
system,  the  elaboration  index  pem  — ^  Pmr  will  retrieve  not  only  motors  but  also  motor-gear 
assemblies  that  were  generated  by  the  elaboration  index  pem  Pmr  Pmr  reducing 
search.  The  synthesis  procedure  can  also  be  improved  by  caching  often  used  components 
and  assemblies  and  thus  speeding  up  the  retrieval  process. 
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4.  Domain  heuristics  for  elaboration  and  matching 


The  algorithm  presented  in  the  previous  section  uses  a  variety  of  heuristics  to  focus  the  search 
for  cases.  Domain  heuristics  that  capture  knowledge  regarding  device  relations,  nature  of 
inputs  and  outputs  and  device  topologies  are  used  to  guide  the  search  to  find  solutions 
efficiently.  In  the  worst  case,  the  elaboration  tree  search  is  exponential  in  nature.  In  the 
following  subsections,  we  present  heuristics  that  guide  elaboration,  retrieval  and  matching 
in  the  synthesis  algorithm. 


4.1.  Elaboration  and  retrieval  heuristics 

Elaboration  indices  in  the  elaboration  tree  are  searched  breadth-first  to  obtain  the  smallest 
number  of  combination  of  components  in  a  design.  An  elaboration-index  can  fail  to  retrieve 
cases  either  when  there  are  no  devices  that  span  the  requisite  energy  domains  or  the  combi¬ 
nation  of  devices  that  spans  the  required  energy  domains  fails  the  case- verification  procedure. 
With  the  exception  of  the  root  index,  if  no  cases  are  retrieved  for  a  particular  elaboration  in¬ 
dex  (called  Efaii)  in  the  elaboration  tree  due  to  the  first  possible  reason,  further  exploration 
of  elaboration  indices  of  which  Efaii  is  a  sub-index  is  pruned.  If  no  cases  were  retrieved  for 
the  elaboration  index  pmt  Pmr  PmRi  search  will  be  aborted  for  the  elaboration  index 
Pmt  Pmt  Pmr  Pmr  Pmr- 

An  important  stage  in  the  search  process  is  the  choice  of  an  elaboration  index,  a  node  in 
the  elaboration  tree  for  performing  case  retrieval.  Elaboration  indices  whose  intermediate 
ports  have  the  same  energy  domains  as  the  input  or  output  ports  are  prefered  to  indices 
that  have  a  variety  of  mixed  energy  domains.  The  reasoning  behind  this  heuristic  is  that 
devices  built  from  components  belonging  to  same  energy  domains  are  easier  to  build,  test 
and  control.  Thus  an  elaboration  index  pmt  Pmr  Pmr  will  be  prefered  to  the  index 
Pmt  Phy  Pmr- 

Case  retrieval  is  based  on  the  retrieval  indices  generated  from  an  elaboration  index.  Re¬ 
trieval  indices  that  have  linear  device  relations  between  ports  are  prefered  to  retrieval  indices 
with  sinusoidal  and  other  non-linear  relations.  Key  indices  with  linear  device  relations  are 
used  to  access  the  cases  before  other  combinations  of  device  relations.  This  is  to  ensure  that 
simpler  combinations  of  devices  that  are  easier  to  control  are  generated  before  more  complex 
combinations. 


4.2.  Heuristics  for  symbolic  solving  and  matching  parameter  relations 

Symbolic  solving  of  equations  is  a  critical  step  in  this  synthesis  procedure  and  is  used  as 
a  mechanism  for  verifying  the  combination  of  cases.  Solving  and  matching  input-output 
effort  and  flow  relations  with  time  provides  a  robust  mechanism  for  case  veriflcation.  This 
verification  scheme  is  robust  in  the  sense  that  there  are  no  ad  hoc  validation  rules.  It  is 


36 


considerably  general  to  handle  a  large  variety  of  functions  of  time  as  inputs  and  outputs 
to  devices.  The  procedure  also  enables  verification  of  parameter  trajectories  at  both  the 
morphological  and  parametric  levels. 

Symbolic  equation  solving  critically  depends  on  the  nature  of  the  (1)  device  relations 
and  (2)  input-output  parameter  relations.  In  this  section,  we  present  the  symbolic  solving 
schemes  for  different  types  of  device  relations  and  parameter  relations.  Discussion  of  symbolic 
solving  algorithms  per  se  are  beyond  the  scope  of  this  paper  The  solving  procedure  also 
uses  the  following  rules  for  verification  of  input  and  output  parameter  relations: 

•  It  is  not  possible  for  a  device  to  have  null  input  parameter  relations  and  non-null  output 
parameter  relations.  This  captures  the  fact  that  without  any  input  no  outputs  can  be 
produced. 

•  At  either  input  or  output  port,  if  the  effort  parameter  relation  is  null,  then  the  flow 
parameter  has  to  be  null  and  vice  versa.  This  is  the  constraint  that  to  supply  power 
to  a  system  you  need  to  have  both  effort  and  flow  parameter  as  non-null  entities. 

•  By  convention,  both  effort  and  flow  parameter  relations  must  belong  to  the  same 
quadrant.  This  is  to  enforce  the  constraint  that  power  is  a  scalar  and  is  always  positive. 

Symbolically  solving  for  a  parameter  relation  only  gives  information  about  the  form  of  the 
parameter  relation  as  a  function  of  time.  No  information  is  provided  regarding  the  quadrant 
of  the  parameter  relation.  The  rule  is  that  the  quadrant  of  the  input  parameter  relations  is 
the  same  as  the  output  parameter  relations  unless  the  device  relation  has  a  sinusoidal  term 
involving  an  integral  variable  in  it  or  the  structural  relation  imposes  a  negative  algebraic 
coefficient  of  the  device  relation.  A  sinusoidal  term  in  the  device  relation  can  change  the 
quadrant  of  the  output  only  if  the  value  of  the  integral  variable  is  greater  than  an  odd 
multiple  of  tt.  For  device  relations  involving  non-sinusoidals,  there  is  no  effect  of  the  integral 
variables  in  terms  of  relating  input-output  parameter  relation  quadrants.  The  length  of 
the  interval  of  discretisation  obtained  after  solving  is  equal  to  the  length  of  the  interval  of 
the  input  parameter  relations.  The  symbolic  solving  scheme  also  performs  the  necessary 
integration  required  for  device  relations  involving  effort  and  flow  integral  terms.  During 
symbolic  solving,  for  each  case,  the  procedure  also  checks  if  the  input  parameter  relations  to 
the  device  are  valid  since  the  valid  relations  are  defined  in  the  case  schema. 

Matching  solved  relation,  Psolv,  and  the  design  specification  relation,  Pspec  is  performed 
in  two  stages.  Two  parameter  relations  match  if  both  their  patterns  are  same  i.e.  they 
match  morphologically.  Since  parameter  relations  are  represented  as  trees,  two  patterns 
are  considered  to  match  if  the  nodes  and  leaves  of  the  tree  match  each  other.  A  match  is 
obtained  at  the  device  relation  level,  if  the  numerical  values  at  the  leaves  of  the  trees  are 
considered  as  unconstrained  constants  and  the  literals  at  the  leaves  are  of  the  same  type 
i.e.  effort  or  flow  parameters.  The  literals  at  the  nodes  of  the  tree  must  exactly  match  each 


^We  use  Mathematica[22]  as  a  back-end  to  the  search  mechanism  to  solve  equations. 
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other  since  they  are  names  of  mathematical  functions.  Two  relations  match  parametrically 
if  the  numerical  values  at  the  leaves  of  their  tree  representations  are  equal. 


5.  Discussion  and  concluding  remarks 


The  synthesis  procedure  has  been  implemented  as  part  of  the  CADET  system  [10,  8].  This 
approach  enhances  the  influence  graph  based  synthesis  scheme  by  providing  a  convenient 
scheme  to  link  device  structure  and  behavior.  In  this  section,  we  discuss  the  advantages  and 
limitations  of  this  synthesis  methdology. 

The  features  of  the  proposed  device  model  and  case  representation  are: 

•  The  bond  graph  based  device  model  captures  energy  interactions  between  devices.  The 
notion  of  entities  such  as  components  and  assemblies  are  well-defined  as  also  the  notion 
of  assembling  two  components  i.e.  connecting  devices  at  their  ports.  This  scheme  is 
well-suited  for  reasoning  about  device  dynamic  behavior. 

•  The  device  model  provides  for  integrating  both  conceptual  and  parametric  design  in 
a  coherent  manner.  Also  the  notion  of  device  relations,  structural  relations  and  para¬ 
metric  relations  aid  in  modeling  a  wide  variety  of  device  behaviors  both  in  terms  of 
their  input-output  relation  and  effort-flow  variations  with  time  at  the  input  and  output 
ports. 

•  From  a  case-based  reasoning  point  of  view,  each  case  is  a  unique  device  which  is 
an  instantiation  of  a  prototypical  device  defined  by  the  device  relation.  The  device 
representation  provides  the  device  and  structural  relations  as  a  set  of  discriminatory 
indices  for  retrieving  cases.  The  representation  also  provides  for  a  convenient  scheme 
for  classifying  design  cases  from  the  dynamic  behavior  perspective. 


The  synthesis  algorithm  has  some  limitations.  At  present,  transient  behavior  of  devices 
is  not  addressed.  The  device  models  capture  ideal  energy  behaviors.  Also  only  steady-state 
dynamic  behavior  of  devices  has  been  considered.  In  the  proposed  model,  spatial  orientation 
of  components  has  not  been  represented  and  hence  configuration  design  tasks  are  not  sup¬ 
ported.  Also  the  device  models  do  not  enable  reasoning  about  geometry  and  form.  Device 
topologies  are  considered  to  be  open-loop  wherein  there  are  no  energy  or  signal  feedback  loops 
from  components  downstream  of  the  power-flow  path  to  components  upstream.  Closed-loop 
systems  involve  signal  feedback  from  components  downstream  to  components  upstream.  The 
synthesis  algorithm  generates  only  open-loop  systems.  Though  the  synthesis  procedure  can 
identify  the  open-loop  components  in  a  closed-loop  system,  it  cannot  identify  and  retrieve 
signal  components  that  are  used  to  sense  and  transmit  signals.  Thus  in  solutions  to  the 
gate-drive  system,  the  algorithm  cannot  completely  generate  designs  3  and  4  in  Figure  2. 
Future  work  aims  to  extend  the  capability  of  the  algorithm  to  identify  closed-loop  compo¬ 
nents.  Extension  to  multiple-input  multiple  output  power  systems  is  possible  by  allowing 
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Power  distribution  Power  confluence 

junction  junction 

Figure  13:  Junction  structures  in  elaboration 

for  introduction  of  junctions  by  the  elaboration  procedure.  Junction  structures  as  those 
shown  in  Figure  13  can  be  introduced  to  allow  for  multiple  power  flow  paths.  A  distribution 
junction  provides  for  power  distribution  and  a  confluent  junction  for  power  accumulation. 

We  have  described  a  CBR-based  algorithm  for  synthesis  of  single-input  single  output 
power  drive  devices  based  on  bond  graph  device  models.  The  algorithm  combines  both 
conceptual  and  parametric  design  tasks.  The  synthesis  algorithm  uses  design  information 
regarding  both  device  topology  and  device  behavior.  Future  research  aims  to  extend  the 
synthesis  procedure  for  multiple  input  and  output  power  drive  systems  and  also  consider 
components  that  exhibit  energy  storage  and  dissipation  behaviors. 
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